Currently, the 3rd Generation Partnership Project (3GPP) Service and System Aspects Working Group 1 (SA1) is creating service requirements and use cases for user plane congestion management, as set out e.g. in document [1]. New use cases comprise e.g.:                Use Case 8—Servicing data connection requests/reactivations        Allows the network to identify if the application that initiated a data connection on the UE is an “attended” or a “non-attended” type (i.e. web surfing vs. social network app's periodic updates).        Use Case 11—Multiple applications traffic control over one bearer        Highlights the problem of only using a single PDP context to carry different types of traffic.        Use Case 12—Application Data Priority Control        Operator may want to offer higher priority treatment in the operator network for the applications which are owned by the operator than others owned by service providers, even if the type for the applications is the same, e.g. the IP Multimedia (IM) application belonging to the operator might have higher priority than those belonging to the 3rd party.        Use Case 13—Protocol Optimization        Operators may expect the network to provide protocol optimization capability by using common protocol optimization mechanisms, e.g. Hyper Text Transfer Protocol (HTTP) Multi-Part Response, HTTP Pipelining, Robust Header Compression (ROHC), etc.        
FIG. 1 is an overview showing the overall policy and charging control (PCC) architecture as described in document [3], to which the present invention is applicable. According to document [3], the PCC functionality is comprised by the functions of the Policy and Charging Enforcement Function (PCEF), the Bearer Binding and Event Reporting Function (BBERF), the Policy and Charging Rules Function (PCRF), the Application Function (AF), the Traffic Detection Function (TDF), the Online Charging System (OCS), the Offline Charging System (OFCS) and the Subscription Profile Repository (SPR) or the User Data Repository (UDR).
As defined in document [3], the TDF is a functional entity that performs application detection and reporting of detected application and its service data flow description to the PCRF. The TDF supports solicited application reporting and/or unsolicited application reporting.
The TDF shall detect Start and Stop of the application traffic for the ADC rules that the PCRF has activated at the TDF (solicited application reporting) or which are pre-provisioned at the TDF (unsolicited application reporting). The TDF shall report, unless the notification is muted for the specific ADC Rule in case of solicited application reporting, to the PCRF:                For the Start of application event trigger: the Application identifier and, when service data flow descriptions are deducible, the application instance identifier and the service data flow descriptions to use for detecting that application traffic with a dynamic PCC rule.        For the Stop of application event trigger: the Application identifier and if the application instance identifier was reported for the Start, also the application instance identifier.        
For solicited application reporting, the PCRF can request the TDF to also perform enforcement actions and usage monitoring.
For unsolicited application reporting, the TDF performs only application detection and reporting functionality but neither enforcement actions nor usage monitoring. The TDF should handle each IPv4 address and IPv6 prefix, assuming the max prefix length used in the access network, within a separate TDF session. The PCRF shall, if needed, correlate TDF sessions that correspond to the same IP-CAN session.
As an option to the architectural solution for TDF in FIG. 1, the PCEF can be enhanced with application detection and control feature, i.e. the TDF can be integrated in the same entity with the PCEF, or collocated with the PCEF in the same entity.
Further background information in this regard and additional use cases can be found in documents [1] and [2], for example.